boards: beaglev_fire: improve docs, fix uart, expand RAM #80656
Conversation
|
Hello @AlexCharlton, and thank you very much for your first pull request to the Zephyr project! |
AlexCharlton
changed the title
|
Noting that these doc fixes overlap with #79511. My doc additions do cover the flashing instructions which were noted as missing in that PR. |
|
Hey @AlexCharlton, thanks for the PR! It all looks good to me. I will test it on the Beagle today. |
|
Thanks @con-pax! I should have noted that I tested this out on my Fire, and it Works For Me 🙂 |
con-pax
left a comment
con-pax
left a comment
There was a problem hiding this comment.
LGTM
6.406446] >> *** Booting Zephyr OS build v4.0.0-rc1-79-g464e68645d7f ***
Hello World! beaglev_fire/polarfire/e51464e68645d7 (HEAD -> main, origin/main, origin/HEAD) boards: beaglev_fire: expand RAMpc 0x80000290 0x80000290 <main+24>
|
In addition to fixing the board identifiers, I caught a serious issue in my change. I only just found the authoritative docs for PolarFire memory layout. And this clearly shows that address Instead, we need to use addresses in the 64bit range if we want to span more than 1GB. In particular To accomplish this, I defined a new node in the device tree for this memory region, Here you can see hello world booting into the updated address range: |
|
@jadonk we still don't have you properly set up as a maintainer, apparently... |
In addition to some minor corrections, document the process of flashing the board. Signed-off-by: Alex Charlton <[email protected]>
uart1 is not connected to anything as far as I can tell. uart0 was the previous correctly selected uart, so this changes back to that. Signed-off-by: Alex Charlton <[email protected]>
The Fire has 2GB of RAM, so expand sram1 to use it Signed-off-by: Alex Charlton <[email protected]>
Per PR review. Signed-off-by: Alex Charlton <[email protected]>
Per the docs, the memory at address 0x80000000 ends at 0xC0000000. In other words, the address space is 0x40000000, which is only half of the size we want to map. This means that the upper address space previously mapped was overlapping with the space reserved for non-cached memory. Instead, we map the entire 2GB at 0x1000000000, which is the correct address for cached DDR that occupies more than 1 GB. We defined a new node in the device tree for this memory region, `beaglev.ddr_cached_high`. We did not reuse the `soc` node because we needed to redefine the `#address-cells` to be 2, and doing so would have affected other nodes under `soc`. Signed-off-by: Alex Charlton <[email protected]>
|
rebased to re-trigger incomplete CI |
|
Hi @AlexCharlton! To celebrate this milestone and showcase your contribution, we'd love to award you the Zephyr Technical Contributor badge. If you're interested, please claim your badge by filling out this form: Claim Your Zephyr Badge. Thank you for your valuable input, and we look forward to seeing more of your contributions in the future! 🪁 |
6 participants
This PR makes three small changes, all aimed at improving BeagleV-Fire support.
Update documentation
Aside from some minor clarifications, a "Flashing" section was added, since the steps to flash the Fire in a way that's compatible with the Microchip-provided Hart Software Services (HSS) is not readily accomplished with
west/make flash. An example of west scripts that are able to flash the Fire can be seen here, but I doubt this ought to live in Zephyr proper.Change selected UART
In 166b9bf#diff-01f5d360c1043dce50bf74fbb1cc056d2049160741e483f843c19d081c065252R18 the selected UART was changed from
uart0touart1, presumably to mirror the changes made to the other PolarFire boards. While this makes sense to do for the Icicle kit, from looking at the Fire's schematics, I don't believe any of the UARTs other thanuart0is hooked up to anything.Expand available RAM
sram0is a relatively small region of RAM, meant to be used by the HSS (see Linux device tree). I see no reason whysram1shouldn't occupy the remaining ~2GB present on the Fire. I'm a Zephyr newbie, however, so I'm not sure if there are any reasons why you would want to limit the RAM defined.